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Following  the  fixpoint  theory  of  Scott,  we-  propose  to  define  the 
semantics  of  computer  programs  in  terms  of  the  least  fixpoint s  of 
recursive  programs.  This  allows  one  not  only  to  justify  ail  existing' 
verification  techniques,  hut  also  to  extend  them  to  handle  various 
properties  of  computer  programs,  including  correctness,  termination 
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Introduction 


Substantial  progress  has  recently  been  made  in  understanding  the 
mathematical  semantics  of  programming  languages  as  a  result  of  Scott's 
fixpoint  theory.  Our  main  purpose  in  this  paper  is  to  introduce  the 
reader  to  some  applications  of  this  theory  as  a  practical  tool  for 
proving  properties  of  programs. 

The  paper  consists  of  two  parts. 

In  Part  1  we  first  introduce  the  notion  of  a  recursive  program  and 
its  (unique)  least  fixpoint.  We  describe  the  computational  induction 
method,  a  powerful  tool  for  proving  properties  of  the  least  fixpoint  of 
a  recursive  program.  We  then  illustrate  how  one  could  describe  the 
semantics  of  an  Algol- like  program  P  by  "translating"  it  into  a 
recursive  program  P*  such  that  the  partial  function  computed  by  P  is 
identical  to  the  least  fixpoint  of  P* .  Works  in  this  area  include  those 
of  McCarthy  [1965a,  1965b],  Landin  [1964],  Strachey  [1966],  Mon  is  [1968], 
Bekic  [ 1969 ] ,  Park  [1969],  deBakker  and  Scott  [1969],  Scott  [1970], 

Scott  and  Strachey  [1971],  Manna,  Ness  and • Vuillemin  [1972],  Milner  [1972], 
Weyhrauch  and  Milner  [1972]. 

In  Part  2  of  the  paper  we  illustrate  some  of  the  advantages  of  the 
fixpoint  approach  to  program  semantics.  First,  we  justify  the 
inductive  assertion  methods  of  Floyd  [1967]  and  Hoare  [1969,  1971]. 

Other  verification  methods  such  as  recursion  induction  (McCarthy  [1965a], 
[1965b]),  structural  induction  (Burstall  [ 1969 ] ) ,  fixpoint  induction 
(Park  [1969 j.  Cooper  [1971]),  and  the  predicple  calculus  approach 
(Manna  [1969],  Manna  and  Pnueli  [1970])  can  be  justified  in  much  the 
same  way.  Secondly,  we  emphasize  that  the  fixpoint  approach  suggests 
u  natural  method  for  proving  properties  of  programs:  given  a 
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program  P  ,  we  can  translate  it  into  the  corresponding  recursive 
program  P'  ,  and  then  prove  the  desired  properties  for  the  least 
fixpoint  of  P*  by  computational  induction.  In  contrast  to  other 
existing  methods,  this  approach  gives  a  uniform  way  of  expressing 
and  proving  different  properties,  including  correctness,  termination 
and  equivalence.  This  makes  it  very  convenient  for  machine  implementa¬ 
tion  (Milner  [1972]). 

Warning;  The  reader  should  be  aware  that  some  of  the  results 
presented  in  this  paper  hold  only  under  certain  restrictions  which  are 
ignored  in  this  informal  presentation. 


PART  1.  THE  FIXFOINT  APPROACH  TO  PROGRAM  SEMANTICS 


1*1  Recursive  Programs 

A  recursive  program  is  a  LISP-like  definition  of  the  form 
F(x)  <=  t[F](x)  , 

where  t[F](x)  is  a  composition  of  base  functions  and  the  function 
vaiiable  F  ,  applied  to  the  individual  variables  x  =  (x,y,z, ...)  . 

The  following,  for  example,  is  a  recursive  program  over  the  integers 
F(x,y)  <=  if  X  =  y  then  y+1  else  F(x,F(x-l,y+l))  . 

We  allow  our  base  functions  to  be  partial,  i.e.,  they  may  be 
undefined  for  some  arguments.  This  is  quite  natural,  since  they 
represent  the  result  of  some  computation  which  may  in  general  give 
results  for  some  inputs  and  run  indefinitely  for  others.  We  include 
as  limiting  cases  the  partial  functions  defined  for  all  arguments, 
called  total  functions,  as  well  as  the  partial  function  undefined  for 
all  arguments 

Let  us  consider  now  the  following  partial  functions: 

:  x+1 

fg(x,y) :  if  x  >  y  then  x+1  else  y-1  ,  and 

f^(x>y) •  if  (x  >  y)  A  (x-y  even)  then  x+1  else  undefined  . 

These  functions  have  an  interesting  common  property:  For  each  i 

(l  <  i  <  5)  ,  if  we  replace  all  occurrences  of  F  in  the  program  PQ 

by  f.^  y  the  left  hand  side  and  the  righthand  side  of  the  symbol  <= 

*  / 

yield  identical  partial  functions,  i.e.,-' 

*7 - - - — ' — - 

=  is  an  extension  of  the  regular  =  relation  for  handling  undefined 
values.  a  s  b  is  true  if  both  a  and  b  are  undefined,  but  it  is 
false  if  only  one  of  them  is  undefined. 


fjfoy)  =  if  x  =  y  then  y+1  else  fi(x,fi(x-l,y+l))  . 

We  say  that  the  functions  f±  ,  and  f^  are  fixpoints 
of  the  recursive  program  PQ  . 

Among  the  three  functions,  f^  has  one  important  special  property: 
for  any  (x,y)  such  that  f?(x,y)  is  defined,  i.e.,  (x  >  y)  A  (x-y  even)  , 
both  f^(x,y)  and  are  also  defined  and  have  the  same  value  as 

i*j(x^y)  •  We  say  tln_t  f^  is  "less  defined  than  or  equal  to"  f  and 
fg  ,  and  denote  this  by  f^  c  f^  and  f ^  c  fg  .  It  can  be  shown  that 
f3  has  "this  property  not  only  with  respect  to  and  but  with 
respect  to  all  fixpoints  of  •'he  recursive  program  PQ  .  Moreover, 
f^Cx^y)  is  the  only  function  having  this  property;  f^  is  therefore 
said  to  be  the  least  (defined)  fixpoint  of  . 

One  of  the  most  important  results  related  to  this  topic  is  due  to 
Kleene  [1952],  who  showed  that  every  recursive  program  P  has  a  unique 
least  fixpoint  (denoted  by  fp  )  . 


In  discussing  our  recursive  programs,  the  key  problem  is: 

What  is  the  partial  function  f  defined  by  a  recursive  program  p  ? 
There  are  two  viewpoints. 

(a)  Fixpoint  approach:  Let  it  be  the  unique  least  fixpoint  fp  . 

(h)  Computational  approach:  Let  it  be  the  computed  function  Cp  for 
some  given  computation  rule  C  (such  as  "call  by  name"  or  "call 
by  value'1 ) . 

We  now  come  to  an  interesting  point:  all  the  theory  for  proving 
properties  of  recursive  programs  is  based  on  the  assumption  that  the 
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function  defined  by  a  recursive  program  is  exactly  the  lea3t  fixpoint  fp  . 
That  is,  the  fixpoint  approach  is  adopted.  Unfortunately,  many  programming 
languages  use  implementations  of  recursion  (such  as  "call  by  value"  l) 
which  do  not  necessarily  lead  to  the  least  fixpoint  (Morris  [1968]).^/ 


Let  us  consider,  for  example,  the  following  recursive  program  over 
the  integers 

P1  :  F(x,y)  <=  if  x  =  0  then  1  else  F(x-!,F(x,y)) 

The  least  fixpoint  f  can  be  shown  to  be 

P1 

f^  (x,y)  :  if  x  >  0  then  1  else  undefined  . 

P1 


However,  the  computed  function 
out  to  be 


where  C  is  "call  by  value",  turns 


C„  (x,  y)  :  if  x  =  0  then  1  else  undefined  . 
PI  - - 


Thus,  C  is  properly  less  defined  than  f  —  e.g.,  C  (1,0)  is 
1  *1  F1 

undefined  while  f  (1,0)  =1  . 

*1 

There  are  two  alternative  ways  to  view  this  problem:  (a'  Existing 
computer  languages  should  be  modified,  and  language  designers  and 
implementors  should,  seek  computation  rules  which  always  lead  to  the  least 
fixpoint.  "Call  by  name"  is  one  such  computation  rule,  but  unfortunately 
it  often  leads  to  very  inefficient  computations.  An  efficient  computation 
rule  which  always  leads  to  the  least  fixpoint  can  be  obtained  by  modifying 

—j—  —  — 

It  can  be  shown  in  general  that  for  every  recursive  program  P  and 
any  computation  rule  C  ,  Cp  must  be  less  defined  than  or  equal  to 

fp  ,  i.e.,  Cpc  fp  (Cadiou  [1972]). 
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"call  by  value"  so  that  the  evaluation  of  the  arguments  of  a  procedure 
is  delayed  as  long  as  possible  (Vuillemin  [1972]).  (b)  Theoreticians 

are  wasting  their  time  by  developing  fixpoint  methods  for  proving 
properties  of  programs  which  do  not  compute  fixpoints.  They  should 
instead  concentrate  their  efforts  on  developing  direct  methods  for 
proving  properties  of  programs  as  they  are  actually  executed. 

We  shall  indicate  in  Part  2  of  this  paper  how  the  apparent  conflict 
between  these  views  can  be  resolved  by  a  suitable  choice  of  the  semantic 
definition  of  the  programming  language. 

1.2  The  Computational  Induction  Method 

The  main  practical  reason  for  suggesting  the  fixpoint  approach  is 
the  existence  of  a  very  powerful  tool,  the  computational  induction  method, 
for  proving  properties  of  recursive  programs.  The  idea  of  the  method  is 
essentially  to  prove  properties  of  the  least  fixpoint  fp  of  a  given 
recursive  program  P  by  induction  on  the  level  of  recursion. 

Let  us  consider,  for  example,  the  recursive  program 
P2  :  F(x)  <=  if  x  =  0  then  1  else  x*F(x-l)  , 

over  the  natural  numbers.  The  least  fixpoint  f  (x)  of  this  recursive 

P2 

program  is  tne  factorial  function  x!  . 

Let  us  denote  by  f1(x)  the  partial  function  indicating  the 
"information"  we  have  after  the  i-th  level  of  recursion.  That  is, 
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I 

i  (x)  is  undefined  (for  all  x  .); 

f^x)  is  if  x  =  0  then  1  else  x-f°(x-l)  ,  ! 

'  i  i  1 

i.e.,  if  x  =  0  then  1  else  undefined  ; 

f2(x)  is  if  x  =  0  then  1  else  x*f^(x-l)  , 

i.e.,  if  x  =  0  then, 1  else  x- (if  x-1  =  0  then  1  else  undefined)  , 

i 

or  in  short,  if  x  =  0  y  x  =  1  then  1  else  undefined  ; 


In  general,  for  every  i  ,  i  >  1  , 


which  is 


fX(x)  is  if  x  =  0  then  1  else  x*fx~^'x-l)  , 


if  x  <  i  then  x!  else  undefined  , 


This  sequence  of  functions  has  a  limit  which  is  exactly  the  least  fixpoint 
of  the  recursive  program;  that  is,  >  1 

I 

I  » 

=  xi  . 

i -•  ,  ,  i 

i 

This  will  in  fact  be  the  case  for  any  recursive  program  P  :  if  P 

\ 

is  a  recursive  program  of  the  form  F(x)  <=  t[F](x)  ,  and  fx(x)  is 


defined  by 


f°(x)  is  0  (undefined  for  all  x  ),  and 

!  . 

fX(x)  is  T[fi_1](x)  for  i  >  1 


then 


lia[f  (x)}  =  fp(x) 

i  -»CD 


*/ 

— '  r  „1- 


1,  , 


t [  f  ]  is  the  result  of  replacing  all  bccurrenfces  of  F  in  t[F] 

by  fi_1  .  ’  1  , 


I 


! 


This  suggests  ian  induction  rule  for  proving  properties  of  f  :  To 

I  i  P 

show  that  some  property (  <p  holds  for  fp  ,  i.e.,  q^fp)  ,  we  show  that 

<p(f  )  holds  for  all  i  >  0  ,  pnd  that  (p  remains  true  in  the  limit; 

therefore  we  may  conclude  that  (pdirnff1))  ,  i.e.,  <p(f_)  ,  holds. 

,  i  '  i-« 

i  i 

,  Note  that  it  is  not  true  in  general  that  q>  remains  true  in  the 
limit.  For  example,  for  the  recursive  program  P  introduced  above, 
fx(x)  is  the  non -total  function  if  x  <  i  then  xi  else  undefined  , 
while  11m  (f  i.e.,  f-  ,  is  the  total  function  xi  .  Thus  for 

i  -oo  *2 

<p(f)  being  '1  f  is  not  total",  we  have  that  q^f1)  holds  for  all 

r  i 

i  >  0  ,  while  <p(lim  {f  .})  does  not  hold.  However,  the  limit  property 

i  -*co 

i 

holds  of  a  rather  large  class  of  <p  (called  "admissible  predicates"  — 
see  Manna,..  Ness  and,  Vuillemin  [1972]);  in  particular,  all  the  predicates 

i 

that  we  shall  use  later  have  this  property. 

:  i 

There  are  two  well-known  ways  to  prove  that  q^f1)  holds  for  all 
i  >  0, ,  the  rules  for  simple  and  complete  induction  on  the  level  of 

i  i’  i 

recursion. 

I 

i(a)  Simple  induction: 

I 

i  .  if  q>(f°) :  holds  and  Vi[q>(fi)  =>q>(fi+1)]  holds  , 

then!  q)(fp)  .  holds  . 

(b)  Complete  induction: 

if  Vi{[Vj  such  that  j  <  i)qp(f^)  ]  =»q>(fi)}  holds  ^ 

| - — — — 

i 

then  <p(fD)  holds  . 


*7  “7 - — - s - 

Nojte  that  this  includes  implicitly  the  need  to  prove  q>( f  )  ,  since 
for  i  =:0  there  is  no  j  such  that  t  <  i  . 
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The  simple  induction  rule  is  essentially  the  "p,-rule"  suggested  by 
deBakker  and  Scott  [1969],  while  the  complete  induction  rule  is  the 
"truncation  induction  rule"  of  Morris  [1971].  Scott  actually  suggested 
tue  more  elegant  rule 

if  <p(ft)  holds  and  Vf[<p(f)  =>  <p(T[f  ])  ]  holds  , 
then  <J>(fp)  holds  , 

which  does  not  assume  any  knowledge  of  the  integers  in  its  formulation. 
These  rules  generalize  easily  to  systems  of  mutually  recursive 
definitions. 

Example:  Consider  the  recursive  programs 

P3  :  F(x,y, z)  <=  if  x  =  0  then  y  else  F(x-l,y+z,z) 

and 

P4  :  G(x,y)  <=  if  x  =  0  then  y  else  G(x-l,y+2x-l)  . 

We  would  like  to  prove,  using  computational  induction,  that 

f„  (x,0,x)  =  g^  (x,0)  for  any  natural  number  x  . 

*3  F4 

(Both  functions  compute  the  square  of  x  .) 

For  this  purpose,  we  shall  prove  a  stronger  result  than  the  desired 
one  by  simple  computational  induction.  Proving  a  stronger  result  often 
simplifies  proofs  by  induction,  since  it  allows  the  use  of  a  stronger 
induction  hypothesis.  So,  using 

q>(f,g)  :  VxVy[f(y,x(x-y),x)  =  g(y,x2-y2)]  , 

we  try  to  show  that 

<P(fp  >Sp  )  :  V*Vy[fp  (y,x(x-y),x)  5  (y,x2-y2)] 

*3  *4  f3  ^4 


holds.  The  desired  result  then  follows  by  choosing  x  =  y  .  The 
induction  proceeds  in  two  steps: 

(a)  <p(f°,g°)  ,  i.e.,  fxVy[f°(y-x(x-y),x)  s  g°(y,x2-y2) ]  . 

Trivial,  since  VxVy[  undefined  a  undefined]  . 

(b)  ViMfSg1)  =»q>(fi+\g1+1)3  • 

We  assume 

VxVyl f i( y, x(x-y) , x)  =  gi(y, x2 -y2) ] 

and  prove 

VXVy[fi+1(y,x(x-y),x)  =  gi+1(y,x2-y2) ]  . 

fi+1(y>x(x‘y)/x)  *  if  y  =  0  then  x(x-O)  else  f^y-ljxfo-yJ+Xjx) 

=  if  y  =  0  then  x2  else  ^(y-l^Cx-fy-l))^) 

s  if  y  =  0  then  x2  else  gi(y-l,x2-(y-l)2) 

by  the  induction  hypothesis 

-  if  y  =  0  then  x2-02  else  gi(y-l, (x2-y2)+2y-l) 

_  i+1,  2  2n 

=  C  (y,x  -y  )  . 

1.3  Semantics  of  Algol-like  Programs 

Our  purpose  in  this  section  is  to  illustrate  how  one  can  describe 
the  semantics  of  an  Algol-like  program  P  by  translating  it  into  a 
recursive  program  P*  such  that  the  partial  function  computed  by  p  is 
identical  to  the  least  fixpoint  of  P*  .  The  features  of  Algol  we  consider 
are  very  simple  indeed,  but  there  is  no  theoretical  difficulty  in 
extending  them. 
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The  translation  is  defined  blockwise:  to  each  block  B  (or 
elementary  statement)  we  associate  a  partial  function  f_  describing 
the  effect  of  the  block  (or  statement)  on  the  values  of  the  variables. 
For  example, 

begin  x  :=  x+1;  y  :=  y+l  end  , 
will  be  represented  by  the  function 
f(x,y)  m  (x+l,y+l)  . 

Functions  are  then  combined  to  represent  the  whole  program  using  the 
rule: 


2 


(*)  =  (fB  (*))  • 
B2  B1 


This  definition  is  unambiguous,  since  composition  of  partial  functions 
is  associative,  i.e.. 


(fB  -B  (*))  s  fB  -B  -b  (*)  s  fB  .B  (fB  (x))  • 

B1,B2  B1»B2»B5  B2*V  Bl 


All  that  remains  to  be  done  is  to  describe  the  partial  function 
associated  with  each  elementary  statement  of  the  language.  For 
simplicity,  we  shall  first  consider  only  a  "flowchart able"  subset  of  a 
language,  with  nc  goto  statements  or  procedure  calls.  We  shall  also 
ignore  the  problem  of  declarations. 


1)  Assignment  statements 

if  B  is  x^  :=  E(x)  where  E  is  an  expression, 

fB(x)  is  (xi^-^xi;L,E(x),xi+1,...,xn)  . 


2)  Conditional  statements 


and 


) 


I 


» 


t 


t 


* 


* 


t 


» 


if  B  ie  if  p(x)  then  B.,  else  B~  , 

fB(x)  is  if  p(x)  tuen  f  (£)  else  f_  (x)  . 

"l  *2 

3)  Iterative  statements 

if  B  is  while  p(x)  do  B,  , 

*+*+*+*»*  1 

fg(x)  is  the  least  fixpoint  of  the  recursive  program 

F(x)  <=  if  p(x)  then  F(f_  (x))  else  x  . 

B1  - 

Example;  Let  us  consider  the  following  program  for  computing  in  x 
the  greatest  natural  number  smaller  than  or  equal  to  /a  ,  i.e., 
x  <  a  <  (x+1)  ,  where  a  is  any  natural  number.  (The  computation 

method  is  based  on  the  fact  thrt  1+3+5+  •••+  (2n-l)  »  n2  for  every 
n  >  0  .) 

p5 :  fegj*  fofeg,er  x>y*z; 

x  :=  Oj  y  :*  z  ?•=  1; 
while  y  <  a  do 

begin  x  :=  x+1; 
z  ;=  z+2; 
y  y+z; 

end; 

end. 

/N/VW 

The  partial  function  computed  by  is  identical  to  the  least  fixpoint 
of  P£  ,  where 

P’  :  FQ(a)  <=  F(a, 0,1,1) 

F(a,x,y,z)  <=  if  y  <  a  then  F(a,x+l,y+z+2,z+2) 

else  (a,x,y,z)  . 
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4)  goto  statements 

There  has  been  much  discussion  (see,  for  example,  Dijkstra  [1968], 

Knuth  and  Floyd  [1971],  Ashcroft  and  Manna  [1971])  about  the  usefulness 

of  goto  statements:  they  tend  to  mai'  e  programs  difficult  to  understand 

and  debug,  and  one  Might  prefer  to  use  while  or  for  statements  instead. 

******* 

Without  entering  further  into  this  controversy,  we  shall  see  that  the 
semantics  of  goto,  statements  is  quite  complex.  In  particular,  it  may 
lead  to  systems  of  mutually  recursive  definitions,  and  (not  too  surprisingly) 
it  is  indeed  harder  to  prove  properties  of  programs  with  goto  statements . 

We  consider  two  simple  cases. 

If  we  have  a  block  of  the  form 

begin  ...  ;  L:  B,  ;  ...  ;  B4 ;  goto  L  ;  B,.,  j  ...  j  B  end  , 
**^*******  •*»  ******^/  x  n 

then  we  define 


f  oto  l;B  . . # . -b  (*)  toe  leaBt  flxpoint  of  the  recursive  program 

x+ 1  n 


FL(X)  <-  fBi;  -  ..jBn(X)  * 


If  we  have  a  block  of  the  form 

begin  ...  ;  goto  L  ;  B1  ;  ...  ;  Bi_1  ;  L:  B1  ;  B1+1  ;  ...  ;  Bn  aid  , 
then  we  define 

fgo-fcp  L.B  to  be  toe  least  fiJqioint  of  the  recursive  program 

Fl(x)  <=  .  B  (x)  . 

i’  *  n 


Note  that  we  have  revised  our  rule  of  composition,  since 

s  no^  va-^  when  B  is  a  goto  statement . 

Similarly,  if  we  wish  to  allow  goto*  s  which  jump  out  of 
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iterative  statements  or  branches  of  conditional  statements^  then  we 
must  change  their  semantic  definition  accordingly. 


Examgle:  Let  us  consider  another  version  of  ,  using  only  the 

operations  successor  and  predecessor  • 


P<  :  begin  integer  x,y,z; 

x  :=  0;  y:  =  z  :=  1; 

L:  if  y  <  a  then 

begin  integer  t; 
x  :=  x+1; 
z  :=  z+1; 
t  :=  z+lj 
M:  if  t  >  0  then 

/WS^L' 

begin  y  y+1; 
t  :=  t-lj 


end. 


goto  M; 


end; 

AAA# 

z  :=  z+1;  goto  L; 

AAAA# 

end; 

AAA# 


The  partial  function  computed  by  Pg  is  identical  to  the  least 
fixpoint  of  P£  where 

P6  :  F0(a)  <= 

FL(a,x,y,z)  <=  if  y  <  a  then  FM(a,x+l,y,z+l,z+2) 

else  (a,x,y, z) 

FM(a,x,y,z,t)  <=  if  t  >  0  then  FM(a,x,y+l,z,t-l) 

else  FL(a,x,y,z+l) 

Ik 


Let  us  now  define  the  semantics  of  simple  procedures  without 
parameters.  We  shall  not  discuss  problems  such  as  "side  effects", 
parameter  passing  or  the  procedure  copy-rule  for  call  by  name. 

5)  procedures 

(a)  For  the  non -recursive  procedure 

procedure  P;B 

(where  P  is  the  procedure  name  and  B  is  its  body),  we 
define 

fcaU  tobe  fB(i)  ' 

(b)  For  the  recursive  procedure 

procedure  P:  B[P]  , 

we  define 

fcall  p(x)  be  ^he  least  fixpoint  of  the  recursive 
program  F(x)  <=  fB[p](x) 

where  occurrences  of  call  P  will  be  replaced  by  F  in 
the  semantic  definition  of  • 

6)  An  answer  to  the  problem  of  "call  by  value" 

Our  semantic  definition  of  recursive  procedures  assumes  that  the 
implementation  of  recursion  in  the  language  always  leads  to  the  least 
fixpoint.  If  this  is  not  the  case,  we  must  change  our  semantic  definition: 
to  every  program  P  we  associate  a  recursive  program  Pf  such  that 
the  least  fixpoint  of  P*  will  always  be  identical  to  the  partial 
function  computed  by  P  .  Consider,  for  example,  the  program 

integer  procedure  P( integer  x,y) ; 

P  :=  if  x  =  0  then  1  else  P(x-l,P(x,y)) : 

/vw  /WVW 
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If  the  implementation  is  "call  by  name",  its  semantics  will  be 
fcall  p(x,y)  is  the  least  fixpoint  of 

F(x,y)  <=  if  x  =  0  then  1  else  F(x-l,F(x,y))  . 

However,  if  the  implementation  is  "call  by  value",  its  semantics  will  be 
fcall  p(x'y)  iB  the  least  fixpoint  of 

F(x,y)  <=  if  (x  =  0)  a  def(y)  then  1  else  F(x-l,F(x,y))  , 

where  the  (computable)  predicate  def(y)  is  true  whenever  y  is 
defined,  and  undefined  otherwise. 


PART  2.  APPLICATION  TO  THE  VflRIFICAITfiW  PRfmT.liM 


Our  purpose  in  the  second  part  of  the  paper  is  to  illustrate  some 
of  the  advantages  of  the  fixpoint  approach  to  program  semantics. 

2.1  Justification  of  the  Inductive  Assertions  Method 

The  most  widely  used  method  fov-  proving  properties  of  "flowchart 
programs"  is  presently  the  inductive  assertions  method,  suggested  by 
Floyd  [1967]  and  Naur  [1966].  We  shall  illustrate  the  method  on  the 
simple  program  P^  above.  To  clarify  our  discussion  we  shall  describe 
the  program  as  a  flowchart: 


We  wish  to  show  that  this  flowchart  program,  whenever  it  terminates, 

computes  the  greatest  natural  number  smaller  than  or  equal  to  /a  ,  i.e., 
2  2 

that  x  <  a  <  (x+1)  ,  for  any  natural  number  a  . 


t 


0 


e 


c 


o 


To  do  this  we  associate  a  predicate  Q(a,x,y,  z)  ,  called  an 
inductive  assertion,  with  the  point  labelled  a  in  the  program,  and 
show  that  Q  must  be  true  for  the  values  of  the  variables  (a,x,y, z) 
whenever  execution  of  the  program  reaches  point  a  .  Thus,  we  must 
show:  (a)  that  if  we  start  execution  with  a  >  0  ,  then  the  assertion 

holds  when  point  a  is  first  reached,  i.e.,  that  Q( a, 0,1,1)  holds; 
and  (b)  that  the  assertion  remains  true  when  one  goes  around  the 
loop  from  a  to  a  ,  i.e.,  that  (y  <  a)  A  Q(a,x,y,z)  implies 
Q(a,x+l,y+z+2,  z+2)  .  To  prove  the  desired  result  we  finally  show 
(c)  that  x  <  a  <  (x+l)  follows  from  the  assertion  Q(a,x,y,z) 

when  the  program  terminates,  i.e.,  that  (y  >  a)  a  Q(a,x,y,z)  implies 

2  ? 

x  <  a  <  (x+l) 

To  verify  the  program,  we  take 

Q(a,x,y,z)  to  be  (x2  <  a)  A  (y  =  (x+l)2)  a  (z  =  2xfl)  . 

One  can  then  verify  easily  that  conditions  (a),  (b)  and  (c)  above, 
called  the  verification  conditions,  hold. 

Hoare's  inductive  assertion  method  is  actually  a  generalization  of 
Floyd's  method;  Hoare  [  1969,  1971]  realized  that  if  we  wish  to  apply  the 
method  of  inductive  assertions  to  prove  properties  of  a  large  program,  we 
shall  undoubtedly  have  to  break  the  program  into  smaller  parts,  prove 
what  we  need  about  the  parts,  and  then  combine  everything  together.  We 
will  clearly  break  the  program  into  pieces  in  the  most  convenient  way 
for  the  proof,  and,  since  composition  of  statements  is  associative,  the 
way  in  which  we  group  the  statements  of  the  program  is  irrelevant.  For 
example,  if  the  given  program  is  of  the  form 
P:  B^;  B2;  B?;  B^  , 


C* 
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we  can  associate  the  statements  in  several  different  ways,  e.g.. 


((B^  B2);  B2);  D3  , 

(B^;  (BgJ  B^))j  B^  , 

(BjJ  Bg)  >  (B^;  B4)  , 

or 

®1»  (B2J  (BjJ  BU)) 

Although  the  programs  do  not  look  the  same,  all  of  them  yield  the  same 

least  fixpoint,  and  therefore  they  are  equivalent.  If  we  express  other 

verification  techniques  using  this  notation,  we  find  that  Floyd  and 

Naur  consider  only  the  first  possibility,  i.e.,  grouping  statements  to 

the  left,  while  McCarthy  [1963b]  and  Manna  and  pnueli  [1970]  only 

consider  the  last  possibility,  i.e.,  grouping  statements  to  the  right. 

*  / 

Following  Hoare,  we  express  this  idea  by  writing  [R}B[T]  to . 

* 

mean  that  if  E(x)  holds  before  executing  the  piece  of  program  B  and 
if  B  terminates,  then  T(x)  will  hold  after  executing  B  . 

We  first  apply  verification  rules  to  each  statement  of  the 
program.  Examples  of  such  rules  are: 

(a)  assignment  statement  rule: 

R  z>  implies  [R]  x  :=  E(x)  {S} 

_ _^i _ _ _ 

where  stands  for  the  result  of  replacing  all  occurrences 

xi 

of  x^  in  S  by  E(x)  } 


V 


We  prefer  this  notation  to  Hoare’ s  R[B}T  . 


(b)  conditional  statement  rule: 

{R1)B1(T}  and  {R23B2{T}  implies 

{if  p(x)  then  Rn  else  R0}  if  p(x)  then  B,  else  B0  fT}  .  ^ 

(c)  iterative  statement  rule: 

{RAp(x)}  B  {R}  implies  -  {R-}  while  p(x)  do  B  {RA~p(x)}  . 

We  then  compose  pieces  of  the  program  until  we  get  the  entire 
program,  using  the  following 

(d)  composition  rule: 

WB-JS}  and  {S}B2(T}  implies  {R^jB^T}  , 

(e)  consequence  rules: 

R  3  S  and  {S}B{T}  implies  {r}B{T}  ,  and 

{r)B{S}  and  S  3  T  implies  {r}B{T}  . 


Example .  A  proof  of  the  correctness  of  the  program  ,  given  above, 
could  be  sketched  as  follows. 

First,  we  establish,  using  the  assignment  statement  rule,  the 
following  results: 

Since  a  >  0  3  R(a,0,l,l)  ,  where  R(a,x,y,z)  is 
(x2  <  a)  A  (y  =  (xtl)2)  A  (z  =  2x+l)  ,  we  get 

1 

(1)  {a  >  0}  x  :=  0;  y  :=  z  :=  1  (R(a,x,y,z)}  . 

*7  ■  - 

- '  The  reader  should  be  aware  of  the  difference  between 

(if  p  then  R1  else  Rg)  in  the  mathematical  language,  which  stands 
for  (p  3  R1)  a  (~  p  3  R2)  ,  and  (if  p  then  B^  else  B2)  in  the 
programming  language . 
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s 

I 


I 


* 


* 


Since  R(a,x,y,z)  y,  <  a  =3  R(a,x+l,y+z+2,  z+2)  ,  we  geti 

i 

(2)  (R(a,x,y,  z)  A  y  <  a)  x  x+1;  z  :=  z+2j  y  :=  y+z  {R(a!,x,y,  z)  }  . 

t 

•  1  > 

By  using  the  iterative  statement  rule,  we  get  from  (2) ,  , 

! 

(3)  {R(e',x,y,z)}  while  y  <  a  do  begin  x  :=  x+1;  , 

z  :=  z+2;  .y  :  =  y+z  lend  (R(a,x,y,z)  A  y  >  a)  . 

I  .  ,  l 

11  :  i 

We  now  combine  the  results  of  (1)  and  (3)  using  the  composition  rule 

!  1 

to  obtain  s 

(4)  {a  >  0}  (R(a,x,y,z)  A  y  >  a}  .  ‘  1  ' 

Since  [R(a,x,y,  z)  Ay>a]ux  <  a  <  (x+1)  ,  we  apply  the  cohsequenice  ! 
rule  and  finally  get 

I  !  |  > 

•  ’ 

(5)  (a  >  0}  P  {x2  <  a  <  (x+1)2)  . 

^  1  » 

}  ' 

i  1  | 

*  .  » 

i  . 

It  is  quite  important  that  all  of  Hoare's  verification  rulds  can  in 

t 

fact  be  proved  from  the  semantics  we  gave,  just  by  using  cqiiputational  t  > 
induction.  We  shall  illustrate  thi^  point  by  justifying  two  of  the  most 
powerful  verification  rules :  the  rule  for  while  statements,  and  the  rule 

!  rmrwu  j  j 

for  call  of  recursive  procedures.  For  this  purpose,  we  need  to  relate 
the  notation  {R}  B  {T}  to  our  f£(x)  ,  the  partial!  function  indicating 

^he  change  of  the  values  of  the  variable^  during  the  execution  of  B  . 

1  ^  ‘ 

[R]  B  {T}  simply  means  that  whenever  R(x)  is  true.  *(fB(x))  is  either 
true  (if  B  terminates)  or !  undefined.  We  can  ekpness  this  by  the  relation' 
R(x)  =»  T(fB(x))  ,  1  ! 


I 


I 


adopting  here  the  convention  that  a  =»  b  is  true  whenever  a  or  h 
is  undefined.  |  '  < 

We  are  rejady  now  to  prove  the  following  rules: 

v  l 

(a) ,  rule  for  while  statements 

~  i 

1  The  verification  rule  for  while  statements  indicates  that  if  the 

i 

execution  of  the  body  of  the  while  statement  leaves  the  assertion  R 

.  i  -  ! 

invariant,  R  :  should  hold  upon  termination  of  the  while  statement.  More 
precisely, 

J  i  1 

i 

(R(x)ap(x)}  B  Cr(x) }  implies  [R(x)}  while  p(x)  do  B  {R(x)a~p(x)} 


We  therefore  have  to  prove  the  following  theorem: 


> 1  Vx[R(x)  a  p(x)  =*  R(fB(x))] 
implies 

'  1  ' 

Vx[R(x)  .=»  R(fp(x))  a  ~  p(fp(x))  ]  where 

P  :  F(x)  <=  if  p(x)  then  F(f„(x))  else  x  . 


The  proof , is  by  computational  induction. 

1.  Vx[R(x)  =>  R(f°(x))  A  ~p(f°(x))  ]  is  clearly  true  according  to  our 

i  1 

convention*,  since  R(f°(x))  and  ~  p(f°(x))  are  undefined. 

-  -  i.  *-  i  - 

2.  ,We  assume  Vx[R(x)  =>  R(f  (x))  a  ~p(f  (x))]  and  show 

Vx[R(x)  y  R(f1+1(x))  A  ~p(f1+1(x))]  .  By  definition  of  fi+1 


we , have 


R(fi+1(x))  =  if  p(x)  then  R(f1(f  (x)))  else  R(x)  ,  and 
p(flH(x))  =  if  p(x)  then  p(fi(fp(x)))  else  p(x)  . 


SJ 


! 


* 

We  distinguish  between  two  cases 


Case  2A:  p(x)  is  false.  Then,  R(f*+^(x))  s  R(x)  and 

p(fi+1(x))  =  p(x)  ,  so  that  R(x)  =»  R(fi+1(x))  A~p(fi+1(x))  is  valid. 

Case  2B:  p(x)  is  true.  Then  R(f1+1(x))  s  R(fi(fB(x)))  and 
p(fi+1(x))  =  pCf^f^x)))  .  3y  the  assumption  R(x)  a  p(x)  =*  R(fB(x)) 
holds,  and  since  by  the  induction  hypothesis 
8(fB(*))  *  R^f^i)))  A  ~  p(f^(fB(x)))  ,  we  get 
R(x)  =»  R(fi(f*B(x) ) )  A  ~p(fi(fB(x)))  .  Hence, 

R(x)  =*  R(f*+^(x))  A  ~  p(f^+^(x))  as  desired. 

(b)  Rule  for  recursive  calls 

Let  us  consider  a  recursive  procedure 
procedure  Pj  B[P]  , 

where  P  is  the  name  of  the  procedure  and  B[P]  represents  its  body. 

The  verification  rule  for  proving  properties  of  P  is  quite  similar  to 
computational  induction,  although  its  formulation  might  look  rather 
paradoxical:  in  order  to  prove  a  property  of  the  recursive  procedure  P  , 
one  is  permitted  to  assume  that  the  desired  property  holds  for  the 
body  B[P]  of  the  procedure l  This  can  be  stated  as  follows: 

Vg  [  {R}  g  £t}  implies  {R}  B[g]  {T}  ]  implies  (R)  call  P  (T)  . 

As  Hoare  [1971;  P*  109]  puts  it,  "this  assumption  of  what  we  want  to 
prove  before  embarking  on  the  proof  explains  well  the  aura  of  magic  which 
attends  a  programmer’s  first  introduction  to  recursive  programming". 

¥ 


A  more  rigorous  treatment  would  require  checking  also  the  case  in 
which  p(x)  is  undefined. 


The  rule  however  is  easy  to  justify.  We  have  to  prove  the 
following  theorem: 

Yg[Vx[R(x)  T(g(x))]  implies  VX[R(x)  *  T(fB[g](x))  ]  ] 
implies 

Vx[R(x)  *  T(f(x))]  where 
P :  F(x)  <=  fgjj,j(x)  . 

The  proof  ie  again  by  computatic.ial  induction. 

1.  Vx[R(x)  =.  T(f°(x))]  is  truef  since  T(f^(x))  is  undefined. 

2.  We  assume  Vx[R(x)  *  T(fi(x))  ]  and  show  Vx[R(x)  »  T(fi+1(x))  ]  . 

By  the  induction  hypothesis,  R(x)  =»  TCf^x))  ,  therefore,  by  the 

assumption  of  the  theorem  R(x)  *  T(f  .  (x))  .  Thus,  tram  the 

B[fX] 

definition  of  fi+1  we  get  R(x)  =»  T(fi+1(x))  ,  as  desired. 

2.2  Translation  to  Recursive  Programs 

In  the  present  state  of  the  art  of  verifying  programs,  Hoare's  method 
is  presumably  the  most  convenient  for  proving  the  correctness  of  programs. 
However,  its  main  drawback  is  that  it  can  handle  only  "partial  correctness" 
of  programs,  i.e.,  we  can  only  show  that  the  final  results  of  the  programs, 
if  any,  satisfy  sane  given  input -output  relation.  The  method  does  not 
provide  us  any  means  for  proving  termination,  and  seems  rather  ill-fitted 
for  proving  equivalence  between  programs. 

This  is  another  case  where  our  semantic  definition  of  the  programming 
language  pay*  off:  properties  like  termination  and  equivalence  can  be 


handled  in  exactly  the  same  way  as  partial  correctness.  The  idea  is 
quite  simple:  To  prove  some  property  of  a  given  program  P  ,  translate 
it  to  the  corresponding  recursive  program  P'  ,  and  than  prove  the 
desired  property  for  V  t  by  computational  induction .  In  this  method 
we  actually  still  benefit  from  all  the  advantages  of  koare's  approach 
since  we  may  associate  the  blocks  of  the  program  arbitrarily  at  our 
convenience. 

To  show,  for  example,  that  the  partial  function  defined  by  the 
given  program  P  is  monotonic  increasing,  we  prove 
Vx,y[(x  <  y)  =»  (fp!(x)  <  fpl(y)3  . 

Note  that  it  is  gather  hard  to  express  such  a  property  as  an  input -output 
relation. 

(A)  Termination 

To  show  that  fp  is  total,  or  in  general  that  gcfp  for  some 
function  g  which  is  total  on  the  desired  domain,  we  cannot  simply  use 
computational  induction  choosing  q>(F)  to  be  g  c  F  ,  as  then  q>(f^) 
will  always  he  false.  However,  we  can  overcome  this  difficulty  by 
considering  the  domain  over  which  our  data  range  as  defined  by  a  recursive 
program. 

For  example,  the  natural  numbers  can  be  characterized?/  by  the 
least  fixpoiirt  num(x)  of  the  recursive  program 
N(x)  <=  if  x  =  C  then  true  else  N(x-l)  . 

We  can  now  translate  any  program  P  over  the  natural  n-anbers  into  the 
corresponding  recursive  program  P»  and  show  that  P»  terminates  by 
simply  proving  the  relation 


Vx[mm(x)  c  nun(fpi(x))]  . 

In  other  words,  fp, (x)  is  defined  and  its  value  is  a  natural  number, 
whenever  x  is  a  natural  number. 


(B)  Equivalence 

It  should  be  quite  clear  at  this  point  that  equivalence  of  two 
recursive  programs  is  no  rac.r*  difficult  to  prove  than  the  other 
properties.  Consider,  for  example,  the  two  recursive  programs  over  the 
natural  numbers 

:  F(x)  <=  if  x  -  0  then  1  else  x»F(x-l)  , 
and 

Pg  :  G(x,y,z)  <=  if  X  =  y  then  z  else  G(x,y+1,  (y+1)  »z)  . 

We  want  to  show  that 


V*[fp^(x)  «  gpQ(x,0,l)] 


Note  that  both  f  (x)  and  g_  (x,0,I)  computes 
7  o 

differently:  f  (x)  is  'going  down*  from  x  to 


x!  ,  but  quite 

0  ,  while  g^  (x,0, 1) 
*o 


is  'going  up'  from  0  to  x  .  This  explains  why  a  ''direct"  computational 
induction  fails  in  this  case. 

However,  if  we  consider  the  predicate  x  >  y  over  the  natural 
numbers  to  be  characterized  by  the  least  fixpoint  jje(x,y)  of  the 
recursive  program 


M(x,y)  O  if  x  y  then  true  else  M(x,y+l))  , 

we  can  show  by  computational  induction  that 

Vx,y[fie(x,y)  c  [f  (x)  =  «  (x,y,f  (y) )  ] ]  . 
l7  ^8  P7 

Then,  in  particular,  for  y  =  0  we  get 
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VX[ge(x,0)  c  [fp^(x)  =  gpQ(x,0,l)]] 


9 


i.e.,  for  every  natural  number  x  ,  either  both  f  (x)  and 

7 

Eire  defined  and  equal,  or  both  are  undefined. 

The  proof  is  by  computational  induction  with 


gp  (x,0,l) 
f8 


<p(F)  :  VX,y[F(x,y)  c  [f _  (x)  =  e  (x,y,f  (y) )  ]  ]  . 

p7  ^8  p7 

It  is  clear  that  <p(f^)  holds.  So,  we  assume  that  «p(fi)  holds  and 
show  that  <p(f*+^)  holds,  i.e., 

Vx,y[fi+1(x,y)  c  [f  (x)  =  g^  (x,y,f  (y) )  ]  ]  , 

p7  ^8  p7 

or  in  other  words 


Tx,y[[ii  x  =  y  then  true  else  f*(x,y+l)]  c  [f  (x)  =  *  (x,y,f  (y))J 

P7  ^8  P7 


Tiie  proof  proceeds  easily  by  distinguishing  between  the  two  cases  where 
x  =  y  and  x  f  y  . 

(a)  If  x  =  y  we  get  Vx[true  c  f  (x)  *  f  (x)]  ,  which  clearly  holds. 

F7  7 

(b)  If  x  ^  y  we  get  Vx^f^y+l)  c  [f  (x)  =  a  (x,y,f  (y) )  ]  ]  . 

p7  <B  p7 

> 

Using  the  definitions  of  f  and  g_  we  get 

P7  ^8 

Vx,y[fi(x,y+1)  c  [f _  (x)  =  g^  (x,y+l,f  (y+l))]]  ,  which  holds 

p8  ^8  p7 

by  the  induction  hypothesis. 
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